The present invention relates to a system and method for establishing throughput limits and/or network configurations over a networked system.
Virtual Private Networks (VPNs) are frequently used to connect an enterprise network to one or more remote sites. A VPN permits the establishment of an encrypted data connection between a central site and one or more remote sites using a public or foreign network, such as the Internet, as an intermediary data link. A VPN allows devices within a remote site to seamlessly interact with devices in the central site or another remote site, as if they were locally situated. A VPN router is used to establish such a connection between a network at the remote site, and the central site, by providing secure broadband access to the end-users over a terrestrial broadband network. The VPN router traditionally connects to a VPN gateway at a Network Operations Center (NOC) through a third party Network Access Provider (NAP) network via a modem such as Digital Subscriber Line (DSL), T1, wireless, cable, etc. The type of modem, a component-off-the-shelf (COTS) device, installed at the remote site depends on, e.g., the customer requirements, cost, and service availability from various vendors in different geographical regions.
A service plan (e.g., DSL service plan) offered at each enterprise site's “last mile” (i.e., the link connecting a DSL modem to a DSL Access Multiplexer (DSLAM)) can vary even within a single customer network, or even for a single site over time, say, due to modem retraining. For example, a customer network could have three service plans deployed in the network with different downlink/uplink speeds, such as (1.5 Mbps/384 Kbps), (1.5 Mbps/128 Kbps), or (768 Kbps/128 Kbps), for different remote sites in the customer network. “Downlink/downstream” refers to a transmission direction from the VPN gateway/DSLAM to the VPN router. “Uplink/upstream” refers to the transmission direction from the VPN router to the DSLAM/VPN gateway. This variation in the offered service plans is due to varying circuit characteristics, and the pricing from different DSL vendors in different geographical regions.
To avoid over-driving a last-mile link, the effective throughput limits in each transmission direction must be established and obeyed. Otherwise, the overloaded last-mile link will cause increased latency and/or packet loss.
An important factor to be taken into account for throughput limit calculations is the encapsulation overhead incurred by each IP packet as it traverses down each protocol layer. The particular protocol layers will depend on an underlying network infrastructure. For example, when the IPSec protocol is used, encryption of an IP packet over a VPN tunnel will incur an IPSec overhead.
Since the encapsulation overhead is non-trivial and varies with packet size and with the site-specific networking technology, it is important for a “throughput limiter” (e.g., packet scheduler) at each VPN peer (i.e., the VPN router and the VPN gateway) to take into account the actual underlying network protocol overhead in its available bandwidth calculations in order to avoid buffer overflows by the DSLAM and the DSL modem. Furthermore, the overhead information may be useful in setting the path Maximum Transmission Unit (MTU) and the Transmission Control Protocol (TCP) Maximum Segment Size (MSS) accordingly to avoid packet fragmentation. The VPN gateway may particularly benefit from this information as it communicates with different VPN routers operating in different types of underlying network infrastructures—including non-dedicated local loop networks such as cable and wireless.
Avoiding packet fragmentation not only improves Quality of Service (QoS) but also results in efficient link utilization at each site. In order to figure out the above information, a VPN router should at least know two key configuration parameters from the DSL modem: (1) the WAN Protocol in use (e.g., RFC 2684 Bridged, RFC 2684 Routed, PPPoA, PPPoE); and (2) the ATM Encapsulation Mode (e.g., LLC, VC MUX). Another important factor that should be taken into consideration in a throughput analysis is QoS.
End-user traffic typically consists of: (1) real-time traffic such as voice, (2) interactive traffic such as web browsing and Point-Of-Sale (POS) transactions, and (3) bulk traffic such as FTP. When a VPN peer is given a mix of all types of traffic, real-time traffic gets the most preferential treatment followed by the interactive traffic. In order to provide QoS in such a system, it is well known to those skilled in the art that traffic needs to be classified and prioritized.
However, since the “last mile” in a dedicated local loop network such as DSL operates at significantly lower link speeds compared to the rest of the network, it is important for VPN routers to limit the data throughput in order to ensure that uplink throughput does not exceed the modem's uplink speed. Otherwise, data would pile up in a first-in-first-out (FIFO) fashion in VPN routers, causing increased latency for all packets and, if persistent, causing buffer overflows and packet losses. The net effect would be poor QoS despite the traffic classification and prioritization.
Since the real-time and interactive traffic is bidirectional, it therefore becomes equally important to limit the per-site throughput at the VPN gateway in the downlink direction to ensure that downlink throughput does not exceed the downlink speed at the last mile for the particular site. Otherwise, data would pile up in the DSLAM causing similar increased latency and, if persistent, packet loss.
In summary, an end-to-end throughput limit configuration setup that matches the last mile link speeds is essential to guarantee QoS.
However, since the last-mile link speeds are site-specific and time-varying, a priori throughput limit configuration at a VPN router, and at a VPN gateway, to match each remote site's uplink and downlink speed, respectively, is not practical in a large enterprise network.
Typically, the throughput limits for a VPN router and a VPN gateway, if set, are set to default “one-size-fits-all” values to match the maximum available link speeds in the network. However, this approach presents problems.
For example, a default per-site setting may be employed where the downlink throughput limit is set to 1.5 Mbps at the VPN gateway and the uplink throughput limit is set to 384 Kbps at the VPN router. In this case, a DSL modem having only a 768 Kbps downlink limit and a 128 Kbps uplink limit could be overdriven.
Accordingly, what is needed is a system and method to automatically monitor the last-mile link speeds at each site and automatically set the throughput limit at each VPN peer to match the link speeds.
What is also needed is a system and method whereby the VPN router automatically discovers the network protocols at each site, automatically sets network configurations such as path MTU and TCP MSS in accordance with the employed network protocols, and factors in the network protocol overhead in its available bandwidth calculations; and in combination with this, a system and method to convey the network protocol overhead to the VPN gateway to aid in available bandwidth calculations in the downlink direction.
What is further needed is a system and method to also automatically adjust the throughput limit values in cases where a modem re-trains to different speeds.
What is ultimately needed is a system and method whereby a VPN router queries its DSL modem periodically for its link speeds and uses the learned uplink speed to limit the throughput in the uplink direction, in combination with a system and method to convey the learned downlink speed to a VPN gateway to limit the throughput for each site in the downlink direction to match its downlink speed.
In yet another concern, in a broadband VPN network, the speed of the links after the last mile (i.e., backbone links) are so much faster than an individual broadband connection's speed that: (1) responding to congestion in the backbone of the network by a single remote site does not materially change the congestion; and (2) congestion in the backbone of the network is primarily experienced as packet loss and not by significant changes in latency. As such, taking steps to respond to congestion is important.
Existing TCP acceleration methods use, e.g., a Performance Enhancing Proxy (PEP), to enhance performance of a communications network. See, e.g., U.S. Pat. Nos. 6,973,497, 7,006,480, 7,082,467, 7,219,158, 7,389,533, 7,398,552 and 7,643,416, the entireties of which are incorporated by reference herein. As is well known to those skilled in the art, TCP acceleration may be performed by “spoofing” TCP and carrying the resulting TCP traffic multiplexed on backbone connections (one backbone connection per QoS classification).
Therefore, there is a need for an enhancement to such TCP acceleration methods, to provide good quality of service even in the face of congestion in the non-last mile (i.e., backbone) segments of the network.